Application Number 10/687,989 

Response to Office Action mailed August 21, 2009 

REMARKS 

This amendment is responsive to the Final Office Action dated August 21, 2009. 
Applicant has amended claims 1, 6, 8, 1 1, 18, 27, 32, 39-41 and cancelled claims 5, 7, 9-10, 14, 
16, 23-25, 31, 34, 35, 37 and 38. Claims 2-4, 17, 28-29, and 36 were previously cancelled. 
Claims 1, 6, 8, 11-13, 15, 18-22, 26, 27, 30, 32, 33 and 39-41 are pending upon entry of this 
amendment. 

Amendments 

Applicant has amended claim 1 to include elements previously presented in dependent 
claim 5. 

Applicant has amended claim 8 to include elements previously presented in dependent 
claims 9 and 10. 

Applicant has amended claim 1 1 to include elements previously presented in dependent 
claim 14. 

Applicant has amended claim 1 8 to include elements previously presented in dependent 
claims 23-25. 

Applicant has amended claim 27 to include elements previously presented in dependent 
claim 3 1 . 

This Amendment raises no new issues and require no new search. Furthermore, the 
amendments present the claims in a better form for appeal. Consequently, the Amendment 
should be entered. 

Claim Rejection Under 35 U.S.C. § 103 

In the Final Office Action, the Examiner rejected claims 1, 5, 8-16, 18-27, 30-35 and 
37-41 under 35 U.S.C. 103(a) as being unpatentable over Sankaran (US 2003/0231587) in view 
of "BGP Restart Session After Max-Prefix Limit," Cisco Systems and "TCP/IP Network 
Administration," Hunt. The Examiner rejected claim 7 under 35 U.S.C. 103(a) as being 
unpatentable over Sankaran in view of TCP/IP Network Administration, Hunt. The Examiner 
rejected claim 6 under 35 U.S.C. 103(a) as applied to claims 1 above, and further in view of 
Rochberger et al. (US 6,212,188). Applicant respectfully traverses the rejection. The applied 
references fail to disclose or suggest the inventions defined by Applicant's claims, and provide 
no teaching that would have suggested the desirability of modification to arrive at the claimed 
invention. 

Cisco Systems 
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As a preliminary matter, Applicant submits that all of the rejections based on Cisco 
Systems are improper as the evidence does not establish the reference as prior art. Specifically, 
on form PTO-892 the Examiner cites Cisco Systems as having a date of "2003." The Examiner 
fails to attribute any month or day to the publication. The present application has a filing date of 
October 17, 2003. Consequently, the Examiner has failed to establish that Cisco Systems pre- 
dates the present application and, therefore, has failed to establish that Cisco System qualifies as 
prior art against the present application. Moreover, the Cisco Systems reference has a 2003 
copyright date on pg. 1 but also includes a 2005 copyright date on pg. 21. Consequently, the 
evidence set forth by the Examiner has not established which portions of Cisco Systems were 
even published in 2003. The rejection is improper and should be withdrawn. 

Claims 1, 5, 8-16, 18-27, 30-35 and 37-41 

Applicant has amended claim 1 to include elements previously presented in dependent 
claim 5. Claim 1 requires maintaining a count of routes exported from an exterior routing 
protocol executing on a network device to an interior routing protocol executing on the network 
device and rejecting additional routes exported from the exterior routing protocol executing on 
the network device to the interior routing protocol executing on the network device when the 
count exceeds an export limit. Amended claim 1 also requires updating routing information to 
associate the routes with a maximum metric that defines a maximum distance from the network 
device to neighboring network devices when the count exceeds the export limit, and advertising 
the updated routing information to a network device, as previously presented in claim 5. 

Before addressing the cite prior art, Applicant points the Examiner to paragraphs [0037] 
and [0038] of the present application to aid the Examiner's understanding of the claim language 
by way of example. These paragraphs describe how, upon entering an overload condition when 
the prefix count exceeds the prefix limit, one embodiment of the exemplary router modifies its 
routing information to set routes to a maximum metric so as to effectively direct the other routers 
of the network not to use it when forwarding network traffic and effectively remove the router 
from the network. In this way, the router avoids network failure. These paragraphs state: 

[0037] If the prefix count exceeds the prefix limit, customer router 10 A 
automatically enters an "overload" condition. While operating in the overload 
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condition, customer router 10 A assumes all routes learned from an exterior protocol are 
invalid and clears them from its routing information, e.g., routing tables. Customer 
router 10 A also rebuilds its interior routes, preferably to a maximum metric, e.g., the 
maximum effective "distance " between it and neighboring routers in the network. 
Customer router 10 A advertises the updated routing information with the maximum 
metric to other peer interior routers, e.g., customer routers 10B and IOC 

[0038] In this manner, customer router 10 A effectively directs the other interior 
customer routers 10B and 10C to find other routes through the network, effectively 
removing customer router 10A from the network and avoiding network failure. 
With respect to the elements previously presented in claim 5, the Office Action cited 
Sankaran at ]fl[ 3, 5. In general, Sankaran discloses rejecting routes by a router "based upon the 
volume of routes in the router." Sankaran, *\ [0009]. That is, Sankaran discloses establishing 
thresholds for discarding routes based upon a volume of available storage space of a router. See, 
e.g., Sankaran, \ [0035]. The cited portions of Sankaran describe conventional routing protocols 
(BGP, ISIS) and the fact that some networks may have redundant routes. The techniques by 
which the Sankaran router discards routes from its own route table fails to teach or suggest a 
router advertising routing information that has been rebuild and modified in a certain way so as 
to instruct other routers to temporarily avoid using the router. The cited prior art fails to teach or 
suggest updating routing information to associate the routes with a maximum metric that defines 
a maximum distance from the network device to neighboring network devices when the count 
exceeds the export limit; and advertising the updated routing information to a network device, as 
required by claim 1 . 

Further, Applicant has amended independent claim 8 to include elements previously 
presented in dependent claims 9-10. As amended, claim 8 recites receiving a prefix limit 
command that specifies an export limit and an associated one of a plurality of instances of an 
interior routing protocol executing on a network device, and maintaining respective counts of 
routes exported from an exterior routing protocol executing on the network device to each of the 
instances of the interior routing protocol executing on the network device. Claim 8 further 
requires identifying one of the instances of the interior routing protocol to which the routes were 
exported, comparing the respective count for the identified one of the instances to the prefix limit 
specified by the command for the identified instance, and rejecting additional routes exported to 
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the identified one of the instances of the interior routing protocol based on the comparison when 
the count exceeds the export limit for the instance. 

Before addressing the prior art, Applicant points the Examiner to paragraphs [0044] and 
[0045] of the present application to aid the Examiner's understanding of the claim language by 
way of example. These paragraphs describe how one embodiment of the present invention 
provides a command syntax by which a remote client can submit commands to direct a router to 
apply different prefix limits to different "instances" of a given interior routing protocol executing 
on that router: 

[0044] In accordance with the principles of the invention, remote client 46 may 
interact with management interface 47 to configure router 10 A to operate in accordance 
with the presently described prefix limit mode. Specifically, management interface 47 
supports a command syntax in which a prefix limit command is used to direct router 10 A 
to operate in prefix limit mode. The command syntax allows remote client 46 to specify a 
maximum number of routes that customer router 10 A may export from an exterior 
protocol, e.g., BGP 32 A, to a particular interior routing protocol, e.g., OSPF 32B or ISIS 
32N. In addition, the command syntax allows remote client 46 to apply different prefix 
limits to different "instances " of a given interior routing protocol. For example, remote 
client 46 may specify a different prefix limit for different level of ISIS protocol 32N of 
ISIS or different instances of OSPF. 

[0045] The following illustrates an exemplary syntax for the prefix limit 
command. 

set routing instances instance A { 

set protocols { 

[protocol name] { 

prefix-export-limit [N] 

} 

} 

} 

In the above-illustrated command syntax, the set protocols command directs 
management interface 46 to apply the configuration data to the protocol 32 specified by 
the protocol name parameter. In addition, the instance parameter may be used to 
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identify a particular instance of the specified one of protocol 32. The prefix-export-limit 
command, referred to generally herein as the "prefix limit" command, directs 
management interface 47 to set a prefix limit N for the specified protocol instance. 
With respect to the elements previously presented in claims 9-10, the Examiner cited Sankaran at 
Tnf 43-45 and Cisco pg. 4, step 4 and stated that Cisco teaches "a maximum prefix limit to a 
neighbor is defined." As set forth above, the Examiner has not established that Cisco qualifies as 
prior art and for this reason alone the rejection is improper. Further, Cisco does not refer to 
limits on routes exported between routing protocols on the same router, as recited by the claim. 
Instead, Cisco describes a configuration parameter that limits the number of routes one router 
can receive from another router for a give routing protocol, i.e., BGP, over a communication 
session between the routers. This has nothing to do with a router being able to set different 
prefix limits for different instances for the same interior routing protocol executing on the same 
router, e.g., different instances of OSPF or different instances of ISIS executing on the same 
router. The Examiner is perhaps confusing communication sessions between routers (which may 
all relate to the same BGP routing instance) with different instances of the same routing protocol 
on a router. Consequently, the rejection is improver for at least these additional reasons. 

Independent claim 1 1 recites a method comprising receiving at a network device an 
export limit command from a client, and counting, in response to the export limit command, a 
number of routes exported from an exterior routing protocol process executing on the network 
device to an interior routing protocol process executing on the network device. Amended claim 
1 1 further recites, when the number of routes exported from the exterior routing protocol process 
to the interior routing protocol process exceeds an export limit, operating the network device in 
an overload condition in which the network device: (i) updates routing information of the interior 
routing protocol to clear the routes previously exported from the exterior routing protocol, (ii) 
rebuilds the routing information of the interior routing protocol by updating the routing 
information of the interior routing protocol to associate interior routes with a maximum metric 
that defines a maximum distance from the network device to neighboring network devices, and 
(iii) advertises the updated routing information to another network device. For reasons set forth 
above with respect to claim 1 , the cited references do not teach or suggest rebuilding routing 
information in the manner recited by claim 1 1 to associate interior routes with a maximum 
metric that defines a maximum distance from the network device to neighboring network devices. 
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Moreover, for reasons set forth above, the reference fail to teach or suggest rebuilding the 
routing information in the specific manner when the network device is operating in an overload 
condition because the number of routes exported from an exterior routing protocol on that 
network to an interior routing protocol exceeds an export limit. 

The cited references fail to teach or suggest the element of independent claims 18, 27 and 
33 for reasons similar to those set forth above. 

For at least these reasons, the Examiner has failed to establish a prima facie case for non- 
patentability of Applicant's claims under 35 U.S.C. 103(a). Withdrawal of this rejection is 
requested. 



All claims in this application are in condition for allowance. Applicant respectfully 
requests reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 



CONCLUSION 



Date: October 20, 2009_ 



By: /Kent J. Sieffert/_ 



SHUMAKER & SIEFFERT, PA. 
1625 Radio Drive, Suite 300 
Woodbury, Minnesota 55125 
Telephone: 651.286.8341 
Facsimile: 651.735.1102 



Name: Kent J. Sieffert 
Reg. No.: 41,312 
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